메인 컨텐츠로 건너뛰기
Day 3

어제 세웠던 Try 돌아보기

새롭게 시도할점

  • 데이터 생명주기를 꼼꼼하게 도식화하고 문서화한다. (체득 및 공유의 역할)
  • 고민을 명확히 세운 뒤 동료들에게 빠르게 공유/이야기하자.
  • 일의 우선순위와 디펜던시 파악을 정리하자.
  • time box를 정해두고 정해진 시간에 주어진 업무에 집중하는 시간을 가지자.

Keep

잘 한점. 혹은 유지할만한점

  • SRE팀에 빠르게 보안 검토 문의를 넣었다.
  • ROI 지표를 정의하고, jira 티켓을 세분화하여 작성했다.
  • 이상치 감지해야할 대상을 파악하고 인프라 구성 설계를 했다.
    • 팀 내 37개의 알림톡을 대상으로 이상치 감지를 수행해야함.
  • 매년 연도가 넘어갈때마다 장애가 있었다는 히스토리를 확인했다.
    • 2026년 연도가 넘어가는 상황을 고려해 이상치 탐지를 고려해야겠다는 목표를 세움.
    • 전년도 대비 크리티컬 에러 개수로 비교해볼 수 있을 것 같아 2025년 1월 초 이슈를 파악
      • 날짜 관련 코드 이슈, 데이터 중복 이슈, 코드 장애 이슈 등 연초 크리티컬 이슈 총 3건 확인
    • 유사한 이슈가 발생했을 때 사람이아닌 데이터를 기반으로 판단할 수 있는 플로우가 필요함을 확인.

Problem

문제점. 개선할점

  • 아직 timebox를 잘 세우지 못하는것 같다. 주변에서 들어오는 업무에 대한 컨텍스트 스위칭을 겪고 다시 원래 업무로 바로 돌아오지 못하는 점이 아쉽다.
    • 데이터 생명주기를 꼼꼼하게 도식화하고 문서화한다. (체득 및 공유의 역할) 작업을 수행하지 못했다.
  • 일의 우선순위와 디펜던시 파악을 정리하는 과정에서 헤매는 과정이 있었다.
    • 매출 통합작업과 이상치 탐지작업 두개의 작업에서 갈피를 잘 못잡고있는 모습을 발견할 수 있었다.
    • 매출 통합을 하면서 이상치 탐지도 같이 수행하려는 모습.
    • 두개는 다른 업무인데 무의식중에 계속 디펜던시를 엮게됨. 업무를 쪼개서 생각하지 못하고있음.
  • 12월 중에 SRE에서 신규서비스 인프라 구성이 어렵다는 답변이 온 상태다.
    • 슬랙 봇을 띄우는 선택지 말고 현재 있는 인프라를 활용하여 수행할 수 있는 최선을 선택해봐야겠다.

Try

새롭게 시도할점

  • 매출 통합과 이상치 탐지의 물리적 업무 분리

    • Jira 티켓 분리는 물론, 작업 문서와 메모장까지 탭을 나누어 무의식적인 디펜던시 연결을 강제로 차단한다.
  • 기존 인프라 기반의 우회 전략 수립 및 빠른 싱크

    • 신규 서버 대신 Lambda나 기존 API 서버의 자원을 활용하는 아키텍처를 도출하고, 확정 전 동료들에게 짧게 공유하여 리스크를 체크한다.
  • 컨텍스트 스위칭 방어막 및 리커버리 루틴 도입

    • 외부 요청으로 흐름이 끊겼을 때, 복귀 후 바로 코딩/설계를 하지 않고 '직전 작업 로그 5분 복기' 시간을 가져 컨텍스트를 빠르게 회복한다.
  • 데이터 생명주기 도식화 우선순위 상향

    • 설계의 근거가 되는 데이터 흐름도(Data Flow) 작성을 내일 오전 최우선 순위로 배치하여 '체득 및 공유'의 토대를 마련한다.
  • 2026년 연초 장애 대비 시나리오 작성

    • 파악된 3가지 크리티컬 이슈(날짜, 중복, 코드)를 기반으로 사람이 아닌 데이터가 판단할 수 있는 블랙박스 테스트 케이스를 구체화한다.

느낀점 및 자유로운 생각

무엇을 해결할 것인가?

  • 매출 통합작업
  • 서비스 이상치 탐지 작업

위 두가지 기로에서 계속 혼란이 오는것 같다. 아무래도 무엇을 해결할 것인가? 를 명확하게 지정하지 않아서 생기는 문제같다. 목적이 추상적인걸까..

차근차근 회고를 돌아보면서 정리해보자

1회차에서 확인했던 문제들과 목표는 다음과 같았다.

1. CS 업무 효율화

  • 장애 탐지 소요 시간 (MTTD): 고객 신고 접수 시점(수 시간~수 일) → 시스템 자동 알림 발송(10분 이내)
  • 문제 원인 파악 시간 (MTTR): 건당 평균 30분(수동 쿼리 조회) → 건당 5분 이내(이상치 알림 메시지 확인)

2. 알림톡 모니터링

  • 장애 인지 지연 시간 (Latency): 최대 60분(기존 배치 주기) → 5분 이내(블랙박스 모니터링 주기)
  • 설정 불일치 건수 (Sync Error): 문서 vs Jenkins 설정 불일치 건수 0건 유지 (Config as Code 도입)

CS 업무 효율화, 알림톡 발송 모니터링 이라는 목표를 세웠다.

지금 다시보니 알림톡 발송 모니터링이 CS 업무 효율화에 포함되는것 같다.

CS 업무 효율화 (최상위 목표)

  • Task A. 알림톡 모니터링 개선 (알림/탐지 영역)
  • Task B. 매출 통합 작업 (데이터/원천 영역)

으로 task가 나누어지는것으로 정의를 해봤다.

문제를 정의할수록 나는 그래서 무엇을 해결할 것인가? 에 대한 본질적인 고민이 깊었던 하루였다. 위 두 가지 기로에서 계속 혼란이 왔던 이유는, 결국 두 작업 모두 데이터 신뢰성 확보를 통한 CS 업무 효율화라는 하나의 큰 상위 목표 아래에 있기 때문인 것 같다.

목적지는 같지만 경로가 달라서 둘을 병렬로 섞는순간 두마리 토끼를 놓치게 되는 꼴이 될 것 같다. 결국 알림톡 모니터링은 알림의 영역이고, 매출 통합은 데이터 원천의 영역이다. 이 둘을 명확히 쪼개서 Task를 분리했다.

특히 2026년 연초 장애를 대비해야 한다는 구체적인 타임라인이 생겼으니, 사람이 아닌 데이터를 기반으로 판단하는 플로우를 만드는 데 더 집중해 보려 한다.

인프라 제약 사항이라는 변수가 생겼지만, 오히려 이 기회에 복잡함을 걷어내고 주어진 환경에서 최적의 선택을 해봐야겠다.


Gemini와 이야기해보면서 내일 업무의 Timebox를 정해봤다.

시간분류주요 할 일 (Action Item)비고
09:30 - 11:00Task A데이터 생명주기 도식화 및 인프라 전략 수립

- 37개 알림톡 흐름도 작성
- Lambda 등 가용 인프라 기반 우회 설계
가장 중요한



설계 작업 우선 수행
11:00 - 11:30Task B매출 통합 작업 마일스톤 정리

- Task A와 물리적 분리 (Jira/문서 세팅)
- 데이터 원천 정합성 기준 수립
짧고 굵게
업무 범위 획정
11:30 - 13:00휴식점심 식사 및 휴식컨텍스트 완전 오프
13:00 - 14:00Review오전 작업 로그 기록 및 공유 준비

- 도식화 내용 팀 내 공유 준비
- 오후 업무 시작 전 리커버리 루틴 수행
리커버리 타임 및 싱크 준비
**14:00 - **Execution우선순위에 따른 세부 구현 및 협업

Box에 명시한 시간에는 최대한 집중해보고 업무 흐름을 잘 관리해봐야겠다.